There are two major fabric solutions for the new generation of data centers: Transparent Interconnect of Lots of Links (TRILL) fabric and Virtual eXtensible Local Area Network (VXLAN)/IP fabric. Typically, a TRILL fabric or VXLAN/IP fabric is based on a two-tier fat tree, also called Clos network, where each spine TRILL switch (“RBridge”) or router connects to each leaf RBridge or router and vice versa.
TRILL fabric is based on the Internet Engineering Task Force (“IETF”) TRILL protocol specified in RFC 6325 and which is incorporated herein in its entirety. TRILL provides a new architecture of layer two control and forwarding that enjoys major benefits such as pair-wise optimal forwarding, loop mitigation, multipathing and being provisioning free. The TRILL base protocol supports an active-standby model, via appointed forwarders (AF), to facilitate loop free connectivity between TRILL and non-TRILL networks. An active-active model is proposed in Coordinated Multicast Trees (“CMT”) for TRILL draft-ietf-trill-cmt-01, available at http://tools.ietf.org/html/draft-ietf-trill-cmt-01, which is incorporated herein in its entirety. The active-active model may allow edge RBridges to select disjoint distribution trees for receiving and sending multi-destination traffic.
VXLAN/IP fabric uses existing IP unicast and multicast protocols such as Intermediate System to Intermediate System (“IS-IS”) and Protocol Independent Multicast (“PIM”) for underlay network control and forwarding while employing a new protocol, VXLAN, as the overlay solution. VXLAN is a scheme of layer 2 overlay on top of layer 3, which encapsulates customer frames with a VXLAN header and uses User Datagram Protocol (“UDP”)/IP for transportation. The VXLAN header contains a VXLAN segment ID/VXLAN network identifier (VNID), which is a 24-bit field to identify virtual networks for different tenants. VXLAN tunnel end point (VTEP) is a software or hardware component that performs actual VXLAN encapsulation and decapsulation. The IP address used by a VTEP as the source address for VXLAN encapsulation is called VTEP address. The VTEP address is be learned along with inner source MAC addresses by remote VTEPs. Multi-destination frames in VXLAN are carried in underlying IP multicast packets which use group addresses as destination IP addresses. More details on VXLAN implementations may be found in VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks, draft-mahalingam-dutt-dcops-vxlan-02, available at tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 which is incorporated herein in its entirety.
Two prior approaches for interworking between TRILL fabric and VXLAN/IP fabric have significant limitations. In a first approach, TRILL hello protocol over VXLAN overlay networks may be employed. For example, in FIG. 1, GW115, GW116 and GW117 may exchange TRILL hello Protocol Data Units (“PDUs”), which may be encapsulated in VXLAN with group addresses as destination IP addresses.
This first approach has at least three limitations. First, as load balancing must be done on the VLAN or segment/VNID basis, per flow load balancing is not possible, even for unicast traffic. Second, in order to receive TRILL hello PDUs, gateways need to join all VXLAN group addresses. A gateway may need to drop frames of those VLANs or segments/VNIDs for which it does not serve as appointed forwarder. This results in wasted bandwidth. Finally, if the TRILL hello protocol runs per segment/VNID, the control plane load may become too heavy.
In a second prior approach Virtual port channels (“vPC”) may be employed. For example, in FIG. 1, if GW117 is absent, RTR122 may use a port channel to connect with GW115 and GW116, which may serve as vPC peers.
This second approach also has at least three limitations. First, vPC supports only two peer devices. It will not scale if more than two gateways are needed to handle a large amount of data traffic between TRILL fabric and VXLAN/IP fabric. Second, vPC requires dedicated peer links, which may be either underutilized or overloaded. Finally, vPC is a CISCO proprietary solution, which may not be able to interoperate with third party gateways.
Given the limitations of the above two approaches, embodiments of the present disclosure are designed to provide a standard based solution which can take advantage of the unique characteristic of VXLAN overlay networks, specifically that VXLAN builds on top of a layer three network instead of physical wires.